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REMARKS 

Applicants have amended claims 2, 14, 18, 21 and 27 to correct inadvertent errors and 
without changing the scope of the claims. 

The Examiner stated : 

It is noted that Claim 14 contains an amendment by adding a period (.) at the end of 
the claim. However, the immediate prior version of Claim 14 already contains a period (.) at 
the end of the claim. 

It is noted that Claim 27 contains an amendment that is submitted without markings 
to indicate the changes that have been made relative to the immediate prior version of the 
claim. 

Applicants have amended claim 14 to remove the added period. 

Applicants have checked PAIR, and Applicants respectfully submit that claim 27 in PAIR 
includes markings to indicate the changes that have been made relative to the immediate prior 
version of the claim. 

As such, Applicants respectfully submit that the issues Examiner has raised have been 
addressed. 

The Examiner objected to claims 18, 21 and 27. In particular, the Examiner stated : 
Claims 18, 21, and 27 are objected to because of the following informalities: 

• Claims 18, 21, and 27 contain a typographical error: " [LJoopback" should 
read —loop-back--. 

• Claim 27 contains a typographical error: The semicolon (;) at the end of 
the limitation "an imaging client installed in the memory of the first computer [...]" 
should be changed to a colon (:). 

Appropriate correction is required. 

Applicants have amended claims 18, 21 and 27 in accordance with the Examiner's 
suggestions. 

As such, Applicants respectfully request that the Examiner withdraw these objections. 

Claims 16 and 27 are rejected under 35 U.S.C. 112, second paragraph. In particular, the 
Examiner stated : 

Claims 16 and 27 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
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applicant regards as the invention. 

Claim 16 recites the limitation "the imaging client" in "mediating [... ] sector-based 
I/O requests between the imaging client and the source disk." There is insufficient 
antecedent basis for this limitation in the claim. In the interest of compact prosecution, the 
Examiner subsequently interprets this limitation as reading "the imaging client program" for 
the purpose of further examination. 

Claim 27 recites the limitation "the file system." There is insufficient antecedent 
basis for this limitation in the claim. In the interest of compact prosecution, the Examiner 
subsequently interprets this limitation as reading "a file system" for the purpose of further 
exami nation. Applicant has inadvertently deleted the word "the" from the limitation "the file 
system drivers" in attempting to overcome the rejection. However, the limitation "the file 
system drivers" has sufficient antecedent basis. The claim is not rejected as being indefinite 
for this limitation. 

As to claim 16 : Applicants respectfully submit that claim 16 includes the limitation: 
"mediating, by the operating system, sector-based I/O requests between the imaging client and the 
source disk." Applicants submit that this is the same as "the operating system mediating .... As 
such, Applicants submit that claim 1 6 meets the requirements of 35 U.S.C. 1 1 2, second paragraph. 

As to claim 27 : Applicants have amended claim 27 to correct the lack of antecedent basis for 
the term "the file system." As such, Applicants submit that amended claim 27 meets the 
requirements of 35 U.S.C. 112, second paragraph. 

In light of the above, Applicants respectfully request that the Examiner withdraw this 
rejection. 

Claims 2-5 and 18-20 are rejected under 35 U.S.C. 102(e). In particular, the Examiner stated : 

Claims 2-5 and 18-20 are rejected under 35 U.S.C. 102(e) as being anticipated by 
US 6,477,624 (hereinafter "Kedem"). 

As per Claim 3, Kedem discloses: 

- loop-back mounting a simulated source disk in the second computer so that the 
si mulated source disk is accessible by the operating system as a local disk (see Column 8: 26- 
28, "To OS 102 and BIOS 104, LDIM 202 "pretends" that it is storage device 110. Thus, 
LDIM 202 is completely transparent to OS 102 and BIOS 104."; Column 9: 2-4, "In the 
former case, LDIM 202 emulates the selected image including the geometry of the image."); 
and 

- configuring the simulated source disk as a proxy for the source disk by 
intercepting sector-based I/O requests directed to the simulated source disk and retrieving 
source disk data from the source disk according to the intercepted sector-based I/O requests 
(see Column 3: 62-67 to Column 4: 1 -3, "The purpose of the LDIM is to imitate the LPSD. 
That is, the LDIM, from the computer's perspective, appeai-s exactly like the LPSD. More 
specifically, the LDIM functions to intercept and process requests that are intended to be 



Atty. Docket A28 



9 of 31 



Application 10/611,815 



received by the LPSD, which maynot be in fact installed in the computer.": Column 9: 9-15, 
"... LDIM 202 functions to intercept requests (for example, read/write requests) that are 
intended to be received by storage device 1 10. After a master data image is selected, upon 
intercepting a read request. LDIM 202 is programmed to determine whether the cached data 
image or the selected master data image has the most up to date version of the requested 
data." and 28-32, "If LDIM 202 determines that the cached data image has the most up to 
date version of the requested data, then LDIM202 retrieves the requested data from storage 
device 110 and passes the data back to the component or device from which it received the 
request.": Column 13: 66 and 67 to Column 14: 1 and 2, "Another approach is to add the 
interception and implementation of the LDIM onto the physical persistent storage device 110. 
This functionality would be added before the device's controller (not shown) handles 
requests."). 

As per Claim 2, the rejection of Claim 3 is incorporated; and Kedem further 
discloses: 

- populating a destination image with extracted contents of the source disk in which 
the destination image has files, attributes, and structural relationships between files identical 
to files, attributes, and strucairal relationships between files of the source disk (see Column 1: 
29-38, "The contents of the hard disk (also referred to as the hard disk's "disk image" or "data 
image") define the user's personalized environment: ..." and 53-62, "When the persistent 
storage device is a hard disk, the persistent storage device data image will frequently be 
called a "disk image.""). 

As per Claim 4, the rejection of Claim 3 is incorporated; and Kedem further 
discloses: 

- forwarding the intercepted sector-based I/O requests to the first computer over a 
network (see Column 10: 19-20, "In this situation, LDIM 202 merely forwards all read/write 
requests to the appropriate RDIM 204."). 

As per Claim 5, the rejection of Claim 4 is incorporated; and Kedem further 
discloses: 

- loading an imaging client program in the memory of the first computer, the 
imaging client program not being resident on the source disk (see Column 9: 65-67, "RDIM 
204 preferably includes image manipulation tools. The image manipulation tools allow 
system administrators to manipulate master data images stored on RPSD 206"); and 

- passing the intercepted sector-based I/O requests to the imaging client program, 
the imaging client program directing the intercepted sector-based I/O requests to the source 
disk (see Column 10: 26-29, "It should also be noted that the propagation of write requests 
from LDIM 202 to RDIM 204 for the purpose of updating the master data image can be 
timed to best utilize the network bandwidth."). 

As per Claim 18, Kedem discloses: 

- a first computer having the source disk (see Column 8: 6-7, "The DIMS is 110 a 
client/server system, and thus includes a client 202 and a server 204."); and 

- a second computer having a memory with an operating system and an imaging 
server residing therein, the imaging server including computer executable instructions having 
code to create a simulated source disk that is a representation of information stored on the 
source disk and is accessed by the operating system as a local disk; and code to mount the 
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simulated source disk in the second computer, with said memory including file system drivers 
to detect a file system of the simulated source disk and a network loopback driver 
intercepting sector-based I/O requests directed to the simulated source disk and retrieving 
source disk data from the source disk according to intercepted sector-based I/O requests 
intercepted by the network loopback driver (see Column 1 : 29-38, "The contents of the hard 
disk (also referred to as the hard disk's "disk image" or "data image") define the user's 
personalized environment: ..." and 53-62, "When the persistent storage device is a hard disk, 
the persistent storage device data image will frequently be called a "disk image.""; Column 3: 
62-67 to Column 4: 1-3, "The purpose of the LDIM is to imitate the LPSD. That is, the 
LDIM, from the computer's perspective, appears exactly like the LPSD. More specifically, 
the LDIM functions to intercept and process requests that are intended to be received by the 
LPSD, which may not be in fact installed in the computer."; Column 6: 17-19, "... the 
operating system directs the request to an appropriate device driver for the physical device to 
which the request was made."; Column 8: 6-7, "The DIMS is 1 10 a client/server system, and 
thus includes a client 202 and a server 20." and 19-21, "LDIM 202, as shown in FIG. 2, 
communicates with OS 102 and BIOS 104 using standard interface 1 12 ... " and 26-28, "To 
OS 102 and BIOS 104, LDIM 202 "pretends" that it is storage device 110. Thus, LDIM 202 
is completely transparent to OS 102 and BIOS 104." and 43-44, "... LDIM 202 includes a 
"mini-booter" software program (not shown)." and 47-48, "This is done by emulating a disk 
with the mini-booter installed as a loader." and 63-67 to Column 9: 1, "The mini-booter 
displays the list of available master data images and prompts the user to select one. The 
mini-booter communicates the selection to LDIM 202 and then either reboots the computer 
or resets the BIOS's disk geometry table to the geometry of the selected master data image." 
and 2-4, "In the former case, LDIM 202 emulates the selected image including the geometry 
of the image." and 9-15, "... LDIM 202 functions to intercept requests (for example, 
read/write requests) that are intended to be received by storage device 110. After a master 
data image is selected, upon intercepting a read request, LDIM 202 is programmed to 
determine whether the cached data image or the selected master data image has the most up 
to date version of the requested data." and 28-32, "If LDIM 202 determines that the cached 
data image has the most up to date version of the requested data, then LDIM 202 retrieves the 
requested data from storage device 110 and passes the data back to the component or device 
from which it received the request."; Column 13:66 and 67 to Column 14: 1 and 2, "Another 
approach is to add the interception and implementation of the LDIM onto the physical 
persistent storage device 110. This functionality would be added before the device's 
controller (not shown) handles requests."). 

As per Claim 19, the rejection of Claim 18 is incorporated; and Kedem discloses: 

- a network adapter, residing in said memory, to forward the intercepted sector- 
based I/O requests to the first computer (see Column 10: 19-20, "In this situation, LDIM 202 
merely forwards all read/write requests to the appropriate RDIM 204." and 49-51, "LDIM 
card 308 is equipped with an embedded processor, logic circuits, and memory 310 for 
enabling LDIM 202 to perform its functions."). 

As per Claim 20, the rejection of Claim 19 is incorporated; and Kedem discloses: 

- a first computer memory within the first computer (see Figure 1: 110); and 

- an imaging client installed in the first computer memory (see Column 9: 65-67, 
"RDIM 204 preferably includes image manipulation tools. The image manipulation tools 
allow system administrators to manipulate master data images stored on RPSD 206."), said 
imaging client comprising computer-executable instructions that include code to receive any 
source disk I/O requests issued from the second computer to the first computer, code to direct 
the intercepted sector-based I/O requests to the source disk, and code to pass the retrieved 
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source disk data to the second computer in response to the source disk I/O requests (see 
Column 9: 9-15, "... LDIM 202 functions to intercept requests (for example, read/write 
requests) that are intended to be received by storage device 110. After a master data image is 
selected, upon intercepting a read request, LDIM 202 is programmed to determine whether 
the cached data image or the selected master data image has the most up to date version of 
the requested data." and 28-32, "If LDIM 202 determines that the cached data image has the 
most up to date version of the requested data, then LDIM 202 retrieves the requested data 
from storage device 110 and passes the data back to the component or device from which it 
received the request."; Column 10: 26-29, "It should also be noted that the propagation of 
write requests from LDIM 202 to RDIM 204for the purpose of updating the master data 
image can be timed to best utilize the network bandwidth."). 

Applicants respectfully traverse this rejection. 

As to claim 3 : Applicants respectfully submit that Kedem does not disclose loop-back 
mounting a simulated source disk. In particular, as the Examiner has asserted, LDIM 202 "pretends" 
it is storage device 1 10 so that LDIM 202 is completely transparent to OS 102. However, Applicants 
respectfully submit that this is completely different from mounting a disk, and in addition, when the 
simulated disk is mounted, unlike Kedem where the OS is unaware of LDIM 202, in accordance 
with the invention of claim 3, the operating system in the second computer system is aware of the 
simulated disk. 

As set forth at paragraph [0167] of the specification of the present patent application, "Using 
the loop-back mounting method, the imaging server 2101 makes the source computer' s source disk 
1010 (i.e., the source disk) appear as a local disk from the server operating system's 2200 
perspective; this local disk is referred to as "simulated source disk" 2210." And at paragraph [0168] 
of the specification, "A loop-back driver 221 IN presents (simulates plug-in of) the simulated source 
disk to the server operating system 2200, causing it to detect the disk and instruct each of a set of 
installed and registered file system drivers 2212 to inspect the disk to find any file system that it 
recognizes . Note that the simulated source disk will appear to the server OS 2200 as any other new 
disk device, such as a Firewire or USB external hard disk that a user can hot-plug into a running 
computer. To the server OS, the simulated source disk will thus look like an actual physical device, 
and the OS will try to send IO requests to it. (Emphasis added)" 

U.S. Patent No. 5,991,542 ("Han") cited by the Examiner describes mounting as follows at 
col. 4, lines 32-35: "The mounting of a storage medium refers to the process by which information is 
provided to the file management facility of a computer's operating system, so that the computer can 
access information on the storage medium." In addition, Han states the following regarding 
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mounting at col. 4, line 67-col. 5, line 9: "Each time a volume is mounted, the file manager reads the 
volume information from the logical block and stores it in a predetermined area of the computer's 
working memory, e.g. its RAM. Once the file manager has retrieved and stored the volume 
information, the volume is considered to be mounted, and the file manager can access information 
contained in the remaining blocks of the volume. A volume becomes unmounted when the file 
manager releases the memory that was used to store the volume information." 

As the Examiner can readily appreciate from the above, Kedem does not teach or disclose in 
any manner mounting a simulated source disk in the second computer so that the simulated source 
disk is accessible by the operating system as a local disk since Kedem does not teach mounting 
LDIM 202. 

In addition, Applicants respectfully submit that Kedem does not disclose configuring the 
simulated source disk as a proxy for the source disk by intercepting sector-based I/O requests and 
retrieving source disk data from the source disk according to the intercepted requests. In particular, 
in Kedem, LDIM 202 intercepts requests for a real storage device, i.e., storage device 110, on 
computer 100, whereas , in accordance with the invention of claim 3, sector-based I/O requests 
aimed at a simulated disk are intercepted, and disk data are retrieved from a real disk on a second 
computer. 

In light of the above, Applicants respectfully submit that claim 3 is not anticipated by Kedem. 

As to claim 2 : Claim 2 depends from claim 3. As such, Applicants submit that claim 2 is not 
anticipated by Kedem for the same reasons set forth above with respect to claim 3. In addition, 
Applicants respectfully submit that nothing in Kedem discloses, in any manner whatsoever, a step of 
"populating a destination image with extracted contents of the source disk in which the destination 
image has files, attributes, and structural relationships between files identical to files, attributes, and 
structural relationships between files associated with the source disk." 

In light of the above, Applicants respectfully submit that claim 2 is not anticipated by Kedem. 

As to claim 4 : Claim 4 depends from claim 3. As such, Applicants submit that claim 4 is not 
anticipated by Kedem for the same reasons set forth above with respect to claim 3. 

As to claim 5 : Claim 5 depends from claims 3 and 4. As such, Applicants submit that claim 
5 is not anticipated by Kedem for the same reasons set forth above with respect to claims 3 and 4. In 
addition, Applicants respectfully submit that nothing in Kedem discloses, in any manner whatsoever, 



Atty. Docket A28 



13 of 31 



Application 10/611,815 



a step of "loading an imaging client program in the memory of the first computer, the imaging client 
program not being resident on the source disk. (Emphasis added)" 

In light of the above, Applicants respectfully submit that claim 5 is not anticipated by Kedem. 

As to claim 18 : Applicants respectfully submit that claim 18 requires code to mount a 
simulated source disk in a second computer. As set forth above in response to the rejection of claim 
3, even assuming (for sake of argument) that LDIM 202 is a simulated source disk (it is not), Kedem 
does not teach mounting a simulated source disk (see the discussion of mounting set forth above with 
respect to the rejection of claim 3). In addition, even assuming for sake of argument that LDIM 202 
is a simulated source disk (it is not), Kedem does not disclose memory in the second computer 
including file system drivers to detect a file system of the simulated source disk. 

In light of the above, Applicants respectfully submit that claim 18 is not anticipated by 
Kedem. 

As to claim 19 : Claim 19 depends from claim 1 8. As such, Applicants submit that claim 19 
is not anticipated by Kedem for the same reasons set forth above with respect to claim 18. 

In light of the above, Applicants respectfully submit that claim 19 is not anticipated by 
Kedem. 

As to claim 20 : Claim 20 depends from claims 18 and 19. As such, Applicants submit that 
claim 20 is not anticipated by Kedem for the same reasons set forth above with respect to claims 18 
and 19. In addition, Applicants respectfully submit that nothing in Kedem discloses, in any manner 
whatsoever, a step of "loading an imaging client program in the memory of the first computer, the 
imaging client program not being resident on the source disk. (Emphasis added)" 

In light of the above, Applicants respectfully submit that claim 20 is not anticipated by 
Kedem. 

In light of the above, Applicants respectfully request that the Examiner withdraw this 
rejection. 

Claim 6 is rejected under 35 U.S.C. 103(a). In particular, the Examiner stated : 

Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kedem in 
view of US 7,000,231 (hereinafter "Gold"). 

As per Claim 6, the rejection of Claim 5 is incorporated; however, Kedem does not 

disclose: 
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- loading a secondary operating system in the memory of the first computer, said 
secondary operating system not being present on the source disk and mediating I/O requests 
between an imaging client program and the source disk. 

Gold discloses: 

- loading a secondary operating system in the memory of the first computer, said 
secondary operating system not being present on the source disk and mediating I/O requests 
between an imaging client program and the source disk (see Column 3: 23-28, "A utility can 
then be used to reset a system identification of the computer entity, before switching to a 
secondary operating system to complete a build process." and 38-40, "A build process under 
control of a secondary "emergency" operating system can copy a fully installed primary 
operating system onto an operating system back-up volume."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Gold into the teaching of Kedem to 
include loading a secondary operating system in the memory of the first computer, said 
secondary operating system not being present on the source disk and mediating I/O requests 
between an imaging client program and the source disk. The modification would be obvious 
because one of ordinary skill in the art would be motivated to guarantee creation of an 
uncorrupted complete copy of the primary operating system (see Gold -Column 3: 41-43). 

Applicants respectfully traverse this rejection. 

Claim 6 requires "loading a secondary operating system in the memory of the first computer, 
said secondary operating system not being present on the source disk . (Emphasis added)" However, 
Gold teaches the opposite. For example, at col. 3, lines 52-62 Gold states: "According to a first 
aspect of the present invention there is provided a method of manufacture of an operating system 
master disk template for installing at least one operating system onto a computer entity, said 
manufacturing method comprising the steps of: building a primary operating system on a first 
partition of a data storage device; building a secondary operating system on a second partition of said 
data storage device ; and building an installation component on a third partition of said data storage 
device. (Emphasis added)" In addition, at col. 3, line 63-col. 4, line 10, Gold states: "According to a 
second aspect of the present invention there is provided a method of manufacture of a computer 
entity, said computer entity comprising at least one data processor and at least one data storage 
device, said method characterized by the steps of: partitioning said data storage device into a 
plurality of partitions; installing a primary operating system onto a first said partition of said data 
storage device; installing a secondary operating system onto a secondary said partition of said data 
device ; installing an initialization component onto a third partition of said data storage device; and 
after installation of said primary and secondary operating systems, deleting said installation 
component. (Emphasis added)" In further addition, at col. 4, lines 25-40, Gold states: "According to 
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a third aspect of the present invention there is provided a method of producing a production version 
of an operating system for installation into a production version computer entity, said method 
comprising the steps of: creating an operating system master disk template having a plurality of 
partitions, wherein a primary operating system is stored on a first said partitions, a secondary 
operating system is stored on a second said partition , and an installation component is stored on a 
third said partition; loading said master disk template into a mastering computer entity to create an 
image of said master disk template on said mastering computer entity; and replicating said master 
disk image by loading said master disk image from said mastering computer entity onto said 
production computer entity. (Emphasis added)" 

Applicants respectfully submit that even if a person of ordinary skill in the art were to 
combine Kedem and Gold in the manner suggested by the Examiner, that person would not arrive at 
the invention of claim 6 at least because that person would store a second operating system on the 
source disk. As such, Applicants respectfully submit that claim 6 is patentable over Kedem in view 
of Gold. 

In light of the above, Applicants respectfully request that the Examiner withdraw this 
rejection. 

Claims 7-8, 12-13, 15-16, 21-23 and 27 are rejected under 35 U.S.C. 103(a). In particular, 
the Examiner stated : 

Claims 7, 8, 12, 13, 15, 16, 21-23, and 27 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Kedem in view of US 5,991,542 (hereinafter "Han"). 

As per Claim 7, the rejection of Claim 2 is incorporated; and Kedem further 
discloses: 

- mounting the destination image in an uninitialized state in the second computer as 
a simulated destination disk (see Column 8: 63-67 to Column 9: 1 , "The mini-booter displays 
the list of available master data images and prompts the user to select one. The mini-booter 
communicates the selection to LDIM 202 and then either reboots the computer or resets the 
BIOS's disk geometry table to the geometry of the selected master data image."); 

- intercepting sector-based I/O requests directed to the simulated destination disk 
and directing the contents of the intercepted sector-based I/O requests to the destination 
image (see Column 9: 9-15, "... LDIM 202 functions to intercept requests (for example, 
read/write requests) that are intended to be received by storage device 110. After a master 
data image is selected, upon intercepting a read request, LDIM 202 is programmed to 
determine whether the cached data image or the selected master data image has the most up 
to date version of the requested data."); and 

- copying files of at least one file system of the simulated source disk to the 
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corresponding file system of the simulated destination disk (see Column 9: 48-51, "It is 
envisioned that a user who uses the DIMS would initially copy the data image stored on 
storage device 110 onto RPSD 206 and then always select that image as the master data 
image."). 

However, Kedem does not disclose: 

- retrieving partition and file system layout information from the source disk; and 

- formatting the simulated destination image to have the same partitioning and file 
system(s) as the simulated source disk and thus of the source disk. 

Han discloses: 

- retrieving partition and file system layout information from the source disk (see 
Column 4: 41-44, "A larger storage device, such as a hard disk or a file server, can be 
divided into many different volumes, or partitions, each of which can be formatted in a 
different manner."); and 

- formatting the simulated destination image to have the same partitioning and file 
system as the simulated source disk and thus of the source disk (see Column 4: 64-67, "This 
information is initially created when the volume is initialized, or formatted, and modified 
thereafter whenever the file management system writes information to the volume."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Han into the teaching of Kedem to 
include retrieving partition and file system layout information from the source disk; and 
formatting the simulated destination image to have the same partitioning and file system as 
the simulated source disk and thus of the source disk. The modification would be obvious 
because one of ordinary skill in the art would be motivated to create a disk image that has 
properties of the physical storage device (see Han -Column 3: 30-34). 

As per Claim 8, the rejection of Claim 7 is incorporated; and Kedem further 
discloses: 

- converting the intercepted sector-based I/O requests to the simulated destination 
disk into sector accesses within the destination image (see Column 9: 36-39, "Upon receiving 
the read request, RDIM 204 locates and reads the requested data from the selected master 
data image stored on RPSD 206 and then transmits the data back to LDIM 202."). 

As per Claim 12, the rejection of Claim 7 is incorporated; and Kedem further 
discloses: in which the source disk is a source virtual disk (see Column 1: 53-62, "When the 
persistent storage device is a hard disk, the persistent storage device data image will 
frequently be called a "disk image.""). 

As per Claim 13, the rejection of Claim 12 is incorporated; and Kedem further 
discloses: 

- in which the destination disk is a physical disk (see Figure 1: 1 10). 

As per Claim 15, the rejection of Claim 7 is incorporated; and Kedem further 
discloses: 

- in which the first computer is the same as the second computer (see Column 8: 6- 
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7, "The DIMS is 110 a client/server system, and thus includes a client 202 and a server 
204.")- 

As per Claim 16, Kedem discloses: 

- in a second computer that includes an operating system that has file system 
software thai detects a file system of disks mounted in the second computer, while the source 
disk is in an unmodified, unprepared state, extracting the contents of the source disk, defining 
extracted contents, and populating a destination image with the extracted contents of the 
source disk such that the destination image may have a different sector-by-sector content than 
the source disk but a destination file system logically equivalent to the at least one source file 
system, with identical files, attributes, and structural relationships between files as the source 
disk (see Column 1 : 2938, "The contents of the hard disk (also referred to as the hard disks 
"disk image" or "data image") define the user's personalized environment: ... " and 53-62, 
"When the persistent storage device is a hard disk, the persistent storage device data image 
will frequently be called a "disk image.""; Column 8: 6-7, "The DIMS is 1 10 a client/server 
system, and thus includes a client 202 and a server 204."); 

- mounting a simulated source disk in the second computer so that the simulated 
source disk is accessible by the operating system as a local disk (see Column 8: 63-67 to 
Column 9: 1, "The mini-booter displays the list of available master data images and prompts 
the user to select one. The mini-booter communicates the selection to LDIM 202 and then 
either reboots the computer or resets the BIOS's disk geometry table to the geometry of the 
selected master data image."); 

- configuring the simulated source disk as a proxy for the source disk by 
intercepting sector-based I/O requests directed to the simulated source disk and retrieving 
source disk data from the source disk according to the intercepted sector-based I/O requests 
(see Column 9: 9-15, "... LDIM 202 functions to intercept requests (for example, read/write 
requests) that are intended to be received by storage device 110. After a master data image is 
selected, upon intercepting a read request, LDIM 202 is programmed to determine whether 
the cached data image or the selected master data image has the most up to date version of 
the requested data." and 28-32, "If LDIM 202 determines that the cached data image has the 
most up to date version of the requested data, then LDIM 202 retrieves the requested data 
from storage device 1 10 and passes the data back to the component or device from which it 
received the request."); 

- forwarding the intercepted sector-based I/O requests to the first computer (see 
Column 10: 19-20, "In this situation, LDIM 202 merely forwards all read/write requests to 
the appropriate RDIM 204."); 

- loading an imaging client program into a memory of the first computer (see 
Column 9: 65-67, "RDIM 204 preferably includes image manipulation tools. The image 
manipulation tools allow system administrators to manipulate master data images stored on 
RPSD206."); 

- passing the intercepted sector-based I/O requests to the imaging client program, 
the imaging client program directing the intercepted sector-based I/O requests to the source 
disk (see Column 10: 26-29, "It should also be noted that the propagation of write requests 
from LDIM 202 to RDIM 204 for the purpose of updating the master data image can be 
timed to best utilize the network bandwidth."); 

- mediating, by the operating system, sector-based I/O requests between the 
imaging client program and the source disk (see Column 6: 12-18, "1. An application wishing 
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to read or write a file issues a request to an operating system API for such action." and "3. On 
a miss, or write through, the operating system directs the request to an appropriate device 
driver for the physical device to which the request was made."; Column 8: 19-21, "LDIM 
202, as shown in FIG. 2, communicates with OS 102 and BIOS 104 using standard interface 
112 ... "; Column 9: 9-11, "As is evident from FIG. 2, LDIM 202 functions to intercept 
requests (for example, read/write requests) that are intended to be received by storage device 
110."); 

- mounting the destination image in an uninitialized state in the second computer as 
a simulated destination disk (see Column 8: 63-67 to Column 9: 1 , "The mini-booter displays 
the list of available master data images and prompts the user to select one. The mini-booter 
communicates the selection to LDIM 202 and then either reboots the computer or resets the 
BIOS's disk geometry table to the geometry of the selected master data image."); 

- intercepting sector-based I/O requests directed to the simulated destination disk 
and directing results of the intercepted sector-based I/O requests to the destination image (see 
Column 9: 9-15, "... LDIM 202 functions to intercept requests (for example, read/write 
requests) that are intended to be received by storage device 1 10. After a master data image is 
selected, upon intercepting a read request, LDIM 202 is programmed to determine whether 
the cached data image or the selected master data image has the most up to date version of 
the requested data."); 

- converting the intercepted sector-based I/O requests to the simulated destination 
disk into sector accesses within the destination image (see Column 9: 36-39, "Upon receiving 
the read request, RDIM 204 locates and reads the requested data from the selected master 
data image stored on RPSD 206 and then transmits the data back to LDIM 202."); and 

- copying files of at least one file system of the simulated source disk to the 
corresponding file system of the simulated destination disk (see Column 9: 48-51, "It is 
envisioned that a user who uses the DIMS would initially copy the data image stored on 
storage device 110 onto RPSD 206 and then always select that image as the master data 
image."). 

However, Kedem does not disclose: 

- retrieving partition and file system layout information from the source disk; and 

- formatting the simulated destination image to have the same partitioning and file 
system(s) as the simulated source disk and thus of the source disk. 

Han discloses: 

- retrieving partition and file system layout information from the source disk (see 
Column 4: 41-44, "A larger storage device, such as a hard disk or a file server, can be 
divided into many different volumes, or partitions, each of which can be formatted in a 
different manner."); and 

- formatting the simulated destination image to have the same partitioning and file 
system(s) as the simulated source disk and thus of the source disk (see Column 4: 64-67, 
"This information is initially created when the volume is initialized, or formatted, and 
modified thereafter whenever the file management system writes information to the 
volume."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
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l he invention was made to incorporate the teaching of Han into the teaching of Kedem to 
include retrieving partition and file system layout information from the source disk; and 
formatting the simulated destination image to have the same partitioning and file system(s) as 
the simulated source disk and thus of the source disk. The modification would be obvious 
because one of ordinary skill in the art would he motivated to create a disk image that has 
properties of the physical storage device (see Han -Column 3: 30-34). 

As per Claim 21, the rejection of Claim 18 is incorporated; and Kedem further 
discloses: 

- wherein the imaging server further includes code to generate a simulated 
destination disk in response to the second computer mounting the destination image, with 
said memory further including a local loopback driver, a local adapter and a formatting 
module, with the local loopback driver intercepting sector-based I/O requests directed to the 
simulated destination disk and the local adapter comprising code to convert the intercepted 
sector-based I/O requests to the simulated destination disk into sector accesses within the 
destination image, the imaging server having code to copy files of at least one file system of 
the simulated source disk to the corresponding file system of the simulated destination disk 
(see Column 8: 63-67 to Column 9: 1, "The mini-booter displays the list of available master 
data images and prompts the user to select one. The mini-booter communicates the selection 
to LDIM 202 and then either reboots the computer or resets the BIOS's disk geometry table 
to the geometry of the selected master data image."; Column 9: 9-15, "... LDIM 202 functions 
to intercept requests (for example, read/write requests) that are intended to be received by 
storage device 1 10. After a master data image is selected, upon intercepting a read request, 
LDIM 202 is programmed to determine whether the cached data image or the selected master 
data image has the most up to date version of the requested data." and 36-39, "Upon 
receiving the read request, RDIM 204 locates and reads the requested data from the selected 
master data image stored on RPSD 206 and then transmits the data back to LDIM 202." and 
48-51, "It is envisioned that a user who uses the DIMS would initially copy the data image 
stored on storage device 110 onto RPSD 206 and then always select that image as the master 
data image."). 

However, Kedem does not disclose: 

- the local loopback driver retrieving partition and file system layout information 
from the source disk; and 

- the formatting module comprising code to format the destination image to have 
the same partitioning and file system(s) as the simulated source disk and thus of the source 
disk. 

Han discloses: 

- the local loopback driver retrieving partition and file system layout information 
from the source disk (see Column 4: 41-44, "A larger storage device, such as a hard disk or a 
file server, can be divided into many different volumes, or partitions, each of which can be 
formatted in a different manner."); and 

- the formatting module comprising code to format the destination image to have 
the same partitioning and file system(s) as the simulated source disk and thus of the source 
disk (see Column 4: 64-67, "This information is initially created when the volume is 
initialized, or formatted, and modified thereafter whenever the file management system writes 
information to the volume."). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Han into the teaching of Kedem to 
include the local loopback driver retrieving partition and file system layout information from 
the source disk; and the formatting module comprising code to format the destination image 
to have the same partitioning and file system(s) as the simulated source disk and thus of the 
source disk. The modification would be obvious because one of ordinary skill in the art 
would be motivated to create a disk image that has properties of the physical storage device 
(see Han -Column 3: 30-34). 

As per Claim 22, the rejection of Claim 21 is incorporated; and Kedem further 
discloses: 

- in which the source disk is a virtual disk (see Column 1: 53-62, "When the 
persistent storage device is a hard disk, the persistent storage device data image will 
frequently be called a "disk image.""). 

As per Claim 23, the rejection of Claim 22 is incorporated; and Kedem further 
discloses: 

- in which the destination disk is a physical disk (see Figure 1 : 110). 
As per Claim 27, Kedem discloses: 

- a second computer (see Column 8: 6-7, "The DIMS is 1 10 a client/server system, 
and thus includes a client 202 and a server 204."); 

- a server operating system that resides in the second computer (see Column 8: 6-7, 
" The DIMS is 110 a client/serv er system, and thus includes a client 202 and a server 204."); 

- file system drivers within operating system of the second computer automatically 
detecting at least one file system of disks mounted in the second computer (see Column 6: 
17-19, "... the operating system directs the request to an appropriate device driver for the 
physical device to which the request was made."); 

- an imaging server running within the second computer (see Column 8: 43-44, " 
LDIM 202 includes a "mini-boater" software program (not shown).") and comprising 
computer-executable instructions: 

- for extracting the contents of the source disk, defining extracted contents, and 
populating a destination image with the extracted contents of the source disk such that the 
destination image may have a different sector-by-sector content than the source disk but a 
destination file system logically equivalent to the at least one source file system (see Column 
1: 29-38, "The contents of the hard disk (also referred to as the hard disk's "disk image" or 
"data image") define the user's personalized environment: ... " and 53-62, "When the 
persistent storage device is a hard disk, the persistent storage device data image will 
frequently be called a "disk image.""); 

- for creating a si undated source disk corresponding to the source disk (see Column 
8: 47-48, "This is done by emulating a disk with the mini-booter installed as a loader."); 

- while the source disk is in an unmodified, unprepared state, for mounting the 
simulated source disk in the second computer, file system drivers thereby automatically 
detecting a file system of the simulated source disk and therefore of the source disk and 
exposing a file system to software running on the second computer (see Column 8: 63-67 to 
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Column 9: 1, "The mini -booter displays the list of available master data images and prompts 
the user to select one. The mini-booter communicates the selection to LDIM 202 and then 
either reboots the computer or resets the BIOS's disk geometry table to the geometry of the 
selected master data image."); 

- a network loopback driver intercepting sector-based I/O requests directed to the 
simulated source disk (see Column 9: 9-15, "... LDIM 202 functions to intercept requests (for 
example, read/write requests) that are intended to be received by storage device 110. After a 
master data image is selected, upon intercepting a read request, LDIM 202 is programmed to 
determine whether the cached data image or the selected master data image has the most up 
to date version of the requested data."); 

- a network adapter forwarding the intercepted sector-based I/O requests to the first 
computer (see Column 10: 19-20, "In this situation, LDIM 202 merely forwards all read/write 
requests to the appropriate RDIM 204."); 

- an imaging client installed in the memory of the first computer (see Column 9: 65- 
67, "RDIM 204 preferably includes image manipulation tools. The image manipulation tools 
allow system administrators to manipulate master data images stored on RPSD 206."), said 
imaging client comprising computer-executable instructions: 

- for receiving any source disk I/O requests issued from the second computer to the 
first computer (see Column 9: 9-15, "... LDIM 202 functions to intercept requests (for 
example, read/write requests) that are intended to be received by storage device 110."), 

- for directing the intercepted sector-based I/O requests to the source disk (see 
Column 9: 9-15, "After a master data image is selected, upon intercepting a read request, 
LDIM 202 is programmed to determine whether the cached data image or the selected master 
data image has the most up to date version of the requested data."), and 

- for passing to the second computer source disk data retrieved in response to the 
source disk I/O requests (see Column 9: 28-32, "If LDIM 202 determines that the cached 
data image has the most up to date version of the requested data, then LDIM 202 retrieves the 
requested data from storage device 1 10 and passes the data back to the component or device 
from which it received the request. "; Column 10: 26-29, "It should also be noted that the 
propagation of write requests from LDIM 202 to RDIM 204 for the purpose of updating the 
master data image can be timed to best utilize the network bandwidth."); 

- a local loopback driver intercepting sector-based I/O requests directed to the 
simulated destination disk (see Column 9: 9-15, "... LDIM 202 functions to intercept requests 
(for example, read/write requests) that are intended to be received by storage device 110. 
After a master data image is selected, upon intercepting a read request, LDIM 202 is 
programmed to determine whether the cached data image or the selected master data image- 
has the most up to date version of the requested data."); 

- a local adapter comprising computer-executable instructions for converting the 
intercepted sector-based I/O requests to the simulated destination disk into sector accesses 
within the destination image (see Column 9: 36-39, "Upon receiving the read request, RDIM 
204 locates and reads the requested data from the selected master data image stored on RPSD 
206 and then transmits the data back to LDIM 202."); and 

- the imaging server further comprising computer-executable instructions for 
copying files of at least one file system of the simulated source disk to the corresponding file 
system of the simulated destination disk (see Column 9: 48-51, "It is envisioned that a user 
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who uses the DIMS would initially copy the data image stored on storage device 110 onto 
RPSD 206 and then always select that image as the master data image."). 

However, Kedem does not disclose: 

- a simulated destination disk generated by mounting the destination image in an 
uninitialized stale in the second computer; 

- a local loopback driver retrieving partition and file system layout information 
from the source disk; and 

- a formatting module comprising computer-executable instructions for formatting 
the destination image to have the same partitioning and tile sy stem as the simulated source 
disk and thus of the source disk. 

Han discloses: 

- a simulated destination disk generated by mounting the destination image in an 
uninitialized state in the second computer (see Column 4: 23-26, "In accordance with the 
present invention, the efficiency with which the downloading operation can be carried out is 
enhanced by making the disk image file mountable in each target computer 10."); 

- a local loopback driver retrieving partition and file system layout information 
from the source disk (see Column 4:41 -44, "A larger storage device, such as a hard disk or a 
file server, can be divided into many different volumes, or partitions, each of which can be 
formatted in a different manner."); and 

- a formatting module comprising computer-executable instructions for formatting 
the destination image to have the same partitioning and file system as the simulated source 
disk and thus of the source disk (see Column 4: 64-67, "This information is initially created 
when the volume is initialized, or formatted, and modified thereafter whenever the file 
management system writes information to the volume."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Han into the teaching of Kedem to 
include a simulated destination disk generated by mounting the destination image in an 
uninitialized state in the second computer; a local loopback driver retrieving partition and file 
system layout information from the source disk; and a formatting module comprising 
computer-executable instructions for formatting the destination image to have the same 
partitioning and file system as the simulated source disk and thus of the source disk. The 
modification would be obvious because one of ordinary skill in the art would be motivated to 
create a disk image that has properties o f the physical storage device (see Han -Column 3: 
30-34). 

Applicants respectfully traverse the Examiner's rejection. 

As to claim 7 : Applicants respectfully submit that Kedem does not teach or disclose in any 
manner loop-back mounting a simulated source disk in the second computer (as required by claim 3 
from which claim 7 depends) as discussed above with respect to the rejection of claim 3. Further, 
Applicants respectfully submit that Kedem does not teach or disclose in any manner mounting the 
destination image in an uninitialized state in the second computer as a simulated destination disk as 
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required by claim 7. In particular, Kedem does not teach any simulated destination disk. However, 
even if LDEV1 202 were such a simulated destination disk (as the Examiner asserts), Kedem does not 
teach or disclose that it is mounted in an uninitialized state. Further, as described above with respect 
to the rejection of claim 3, Kedem does not teach or disclose mounting LDLM 202. 

The Examiner asserts that Kedem discloses "copying files of at least one file system of the 
simulated source disk to the corresponding file system of the simulated destination disk" by the 
language "It is envisioned that a user who uses the DIMS would initially copy the data image stored 
on storage device 1 10 onto RPSD 206 and then always select that image as the master data image." 
However, neither storage device 1 10 nor RPSD is a simulated source disk or a simulated destination 
disk. 

The Examiner asserts that Han teaches "formatting the simulated destination image to have 
the same partitioning and file system as the simulated source disk and thus of the source disk" at col. 
4, lines 64-67 which (only) states that a volume is formatted when it is initialized. Applicants 
respectfully submit that this assertion completely omits the fact that neither Kedem nor Han teaches 
or discloses "formatting the simulated destination image to have the same partitioning and file 
system as the simulated source disk and thus of the source disk. (Emphasis added)" 

Lastly, even if a person of ordinary skill in the art were to combine Kedem and Han in the 
manner suggested by the Examiner, that person would not arrive at the invention of claim 7 because 
Kedem and Han do not disclose the missing elements discussed above. Hence, nothing in Kedem or 
Han would make the invention of claim 7 obvious. 

As such, Applicants respectfully submit that claim 7 is patentable over Kedem in view of 

Han. 

As to claim 8 : Claim 8 depends from claim 7. As such, Applicants respectfully submit that 
claim 8 is patentable over Kedem in view of Han for the same reasons set forth above with respect to 
claim 7. 

As to claim 12 : Claim 12 depends from claim 7. As such, Applicants respectfully submit 
that claim 12 is patentable over Kedem in view of Han for the same reasons set forth above with 
respect to claim 7. In addition, neither Kedem nor Han teaches or discloses a virtual disk (see the 
specification at paragraphs (0093) and (0150), among others, referring to virtual disks). As such, 
even if a person of ordinary skill in the art were to combine Kedem and Han in the manner suggested 
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by the Examiner, that person would not arrive at the invention of claim 12 because Kedem and Han 
do not disclose the missing element, i.e., the source virtual disk, required by claim 12. Hence, 
nothing in Kedem or Han would make the invention of claim 12 obvious. 

As to claim 13 : Claim 13 depends from claims 7 and 12. As such, Applicants respectfully 
submit that claim 13 is patentable over Kedem in view of Han for the same reasons set forth above 
with respect to claims 7 and 12. In addition, neither Kedem nor Han teaches, discloses or suggests in 
any manner creating an image of a virtual disk on a physical disk. Hence, nothing in Kedem or Han 
would make the invention of claim 13 obvious. 

As such, Applicants respectfully submit that claim 13 is patentable over Kedem in view of 

Han. 

As to claim 15 : Claim 15 depends from claim 7. As such, Applicants respectfully submit 
that claim 15 is patentable over Kedem in view of Han for the same reasons set forth above with 
respect to claim 7. 

As to claim 16 : Applicants respectfully submit that claim 16 is patentable over Kedem in 
view of Han for at least the following reasons: (a) neither Kedem nor Han teaches or discloses in any 
manner mounting a simulated source disk in the second computer as discussed above with respect to 
the rejection of claim 7; and (b) neither Kedem nor Han teaches or discloses in any manner mounting 
the destination image in an uninitialized state in the second computer as a simulated destination disk 
as discussed above with respect to the rejection of claim 7. Hence, nothing in Kedem or Han would 
make the invention of claim 16 obvious. 

As to claim 21 : Claim 21 depends from claim 18. As such, Applicants respectfully submit 
that claim 21 is patentable over Kedem in view of Han for the same reasons set forth above with 
respect to claim 18. 

As to claim 22 : Claim 22 depends from claims 18 and 21. As such, Applicants respectfully 
submit that claim 22 is patentable over Kedem in view of Han for the same reasons set forth above 
with respect to claims 18 and 21. In addition, as set forth above in regard to the rejection of claim 
12, neither Kedem nor Han teaches or discloses a virtual disk (see the specification at paragraphs 
0093 and 0150, among others, referring to virtual disks). As such, even if a person of ordinary skill 
in the art were to combine Kedem and Han in the manner suggested by the Examiner, that person 
would not arrive at the invention of claim 22 because Kedem and Han do not disclose the missing 
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element, i.e., the source virtual disk, required by claim 22. Hence, nothing in Kedem or Han would 
make the invention of claim 22 obvious. 

As such, Applicants respectfully submit that claim 22 is patentable over Kedem in view of 

Han. 

As to claim 23 : Claim 23 depends from claims 18, 21 and 22. As such, Applicants 
respectfully submit that claim 23 is patentable over Kedem in view of Han for the same reasons set 
forth above with respect to claims 18, 21 and 22. In addition, neither Kedem nor Han teaches, 
discloses or suggests in any manner creating an image of a virtual disk on a physical disk. Hence, 
nothing in Kedem or Han would make the invention of claim 23 obvious. 

As such, Applicants respectfully submit that claim 23 is patentable over Kedem in view of 

Han. 

As to claim 27 : Applicants respectfully submit that claim 27 is patentable over Kedem in 
view of Han for at least the following reasons: (a) neither Kedem nor Han teaches or discloses in any 
manner mounting a simulated source disk in the second computer as discussed above with respect to 
the rejection of claim 7; and (b) neither Kedem nor Han teaches or discloses in any manner mounting 
the destination image in an uninitialized state in the second computer as a simulated destination disk 
as discussed above with respect to the rejection of claim 7. Hence, nothing in Kedem or Han would 
make the invention of claim 27 obvious. 

In light of the above, Applicants respectfully request that the Examiner withdraw this 
rejection. 

Claim 9-11 and 14 are rejected under 35 U.S.C. 103(a). In particular, the Examiner stated : 

Claims 9-11 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kedem in view of Han as applied to Claims 7 and 21 above, and further in view of US 
6,075,938 (hereinafter "Bugnion"). 

As per Claim 9, the rejection of Claim 7 is incorporated; however, Kedem and Han 
do not disclose: 

- in which the destination image is a virtual disk file associated with a virtual 
computer. 

Bugnion discloses: 

- in which the destination image is a virtual disk file associated with a virtual 
computer (see Column 10: 5-7, "Disco virtualizes disks by providing a set of virtual disks 
that any virtual machine can mount."). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Bullion into the teaching of Kedem to 
include in which the destination image is a virtual disk file associated with a virtual 
computer. The modification would be obvious because one of ordinary skill in the art would 
be motivated to support different sharing and persistency models (see Bu anion -Column 10: 



As per Claim 10, the rejection of Claim 9 is incorporated; and Kedem further 
discloses: 

in which the first computer is a physical computer and the source disk is a physical 
disk associated with the physical computer (see Column 8: 6-7, "The DIMS is 110 a 
client/server system, and thus includes a client 202 and a server 204. " and 10-12, "The 
DIMS also includes a persistent storage device (PSD) 206 that can be read from and written 
tobyRDIM204."). 

As per Claim 11, the rejection of Claim 9 is incorporated; however, Kedem and 
Han do not disclose: 

- in which the viraial disk tile is a sparse virtual disk, having a predetermined 
capacity and initial sector contents with null values. 

Official Notice is taken that it is old and well-known within the computing art to 
utilize a sparse virtual disk. Applicant has submitted in the "Background of the Invention" 
section of the specification that a VMM may implement a virtual disk using a sparse, sector- 
based image format (see Page 21 , Paragraph [0094]). Therefore, it would have been obvious 
to one of ordinary skill in the art at the time the invention was made to include in which the 
virtual disk file is a sparse virtual disk, having a predetermined capacity and initial sector 
contents with null values. The modification would be obvious because one of ordinary skill 
in the art would be motivated to keep the virtual disk files small (see Page 21, Paragraph 
[0094]). 

As per Claim 14, the rejection of Claim 7 is incorporated; however, Kedem and 
Han do not disclose: 

- in which the source disk is a first virtual disk associated with a first virtual 
computer and the destination disk is a second virtual disk associated with a second virtual 
computer. 

Bugnion discloses: 



in which the source disk is a first viraial disk associated with a first virtual computer 
and the destination disk is a second viraial disk associated with a second viraial computer 
( sec Column 10: 5-7, "Disco viraializes disks by providing a set of viraial disks that any 
virtual machine can mount."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Bugnion into the teaching of Kedem to 
include in which the source disk is a first virtual disk associated with a first virtual computer 
and the destination disk is a second virtual disk associated with a second virtual computer. 
The modification would be obvious because one of ordinary skill in the art would be 
motivated to support different sharing and persistency models (see Bugnion -Column 10: 7- 
8). 



7-8). 
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As per Claim 24, the rejection of Claim 21 is incorporated; however, Kedem and 
Han do not disclose: 

- in which the destination image is a virtual disk file associated with a virtual 
computer. 

Bugnion discloses: 

- in which the destination image is a virtual disk file associated with a virtual 
computer (see Column 10: 5-7, "Disco virtualizes disks by providing a set of virtual disks 
that any virtual machine can mount."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Bugnion into the teaching of Kedem to 
include in which the destination image is a virtual disk file associated with a virtual 
computer. The modification would be obvious because one of ordinary skill in the art would 
be motivated to support different sharing and persistency models (see Bugnion -Column 10: 
7-8). 

As per Claim 25, the rejection of Claim 24 is incorporated; however, Kedem and 
Han do not disclose: 

- in which the first computer is a physical computer and the source disk is a 
physical disk associated with the physical computer. 

Bugnion discloses: 

- in which the first computer is a physical computer and the source disk is a 
physical disk associated with the physical computer (see Column 10: 5-7, "Disco virtualizes 
disks by providing a set of virtual disks that any virtual machine can mount."). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to incorporate the teaching of Bugnion into the teaching of Kedem to 
include in which the first computer is a physical computer and the source disk is a physical 
disk associated with the physical computer. The modification would be obvious because one 
of ordinary skill in the art would be motivated to support different sharing and persistency 
models (see Bugnion - Column 10: 7-8). 

Applicants respectfully traverse the Examiner's rejection. 

As to claim 9 : Claim 9 depends from claim 7. As such, Applicants repeat the arguments set 
forth above with respect to Kedem and Han. Namely, Applicants respectfully submit that Kedem 
does not teach or disclose in any manner loop-back mounting a simulated source disk in the second 
computer (as required by claim 3 from which claims 7 and 9 depend) as discussed above with respect 
to the rejection of claim 3. Further, Applicants respectfully submit that Kedem does not teach or 
disclose in any manner mounting the destination image in an uninitialized state in the second 
computer as a simulated destination disk as required by claims 7 and 9. In particular, Kedem does 
not teach any simulated destination disk. However, even if LDIM 202 is such a simulated 
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destination disk (as the Examiner asserts), Kedem does not teach or disclose that it is mounted in an 
uninitialized state. Further, as described above with respect to the rejection of claim 3, Kedem does 
not teach or disclose mounting LDEVI 202. 

As additionally set forth above in response to the rejection of claim 7, neither Kedem nor Han 
teaches or discloses "formatting the simulated destination image to have the same partitioning and 
file system as the simulated source disk and thus of the source disk. (Emphasis added)" 

In addition, Applicants respectfully submit that Bugnion does not make up for any of these 
deficiencies. Thus, even if a person of ordinary skill in the art were to combine Kedem and Han and 
Bugnion in the manner suggested by the Examiner, that person would not arrive at the invention of 
claim 9 because neither Kedem nor Han nor Bugnion disclose the missing elements discussed above. 
Hence, nothing in Kedem or Han or Bugnion would make the invention of claim 9 obvious. 

Lastly, a person of ordinary skill in the art would not be motivated to have a destination 
image as a virtual disk file for the reasons set forth in the specification of the pending patent 
application, namely, as set forth at paragraph (0150): "Selecting virtual disks as a common image file 
format is not an obvious choice, since virtual disks use a sector-based format, and this type of format 
is known to have issues when used as a disk image format, as the discussion above on prior art 
explains. Not surprisingly, no contemporary disk imaging system uses virtual disks as image files." 
As additionally set forth in paragraphs (0014), (0015) and (0023): "A first disadvantage of the sector- 
based approach is, when an image is deployed, the destination disk must be at least as large as the 
original disk since the file system metadata on the original disk may encode the disk's capacity and 
assume that it never changes. This metadata is captured into the image file and copied to the 
destination disk. If the destination disk is smaller than the source disk, some sectors that the 
metadata assume exist may not exist on the destination disk, resulting in an inconsistent file system. 
Furthermore, if the destination disk is larger than the source disk, the deployed file system may not 
be able to take advantage of the additional space, since its metadata would assume that the disk has a 
smaller capacity. Another disadvantage of a sector-based format is its inefficiency. A disk may have 
a large number of free sectors, that is, sectors that are not used as data or metadata, and thus have no 
useful content. These sectors may be scattered all over the disk, and may be difficult to identify 
because they generally contain an undefined set of bytes. A free sector's content is undefined 
because the sector may have been used earlier as data or metadata, then released after a file or folder 
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was deleted. Most file system drivers don't erase (i.e., fill with zeros) freed sectors. A sector-based 
image format is therefore inefficient because it may include a disk's unused sectors. ... In summary, 
sector-based disk image formats are subject to two main limitations: the capacity matching problem, 
where the destination disk of deploy operation must be as large or larger than the source disk used to 
create the image, and the efficiency problem, where the image file may contain useless sectors, 
which unnecessarily increases its size and the time it takes to capture or deploy. 

As such, Applicants respectfully submit that claim 9 is patentable over Kedem in view of 
Han and further in view of Bugnion. 

As to claim 10 : Claim 10 depends from claims 7 and 9. As such, Applicants respectfilly 
submit that claim 10 is patentable over Kedem in view of Han and further in view of Bugnion for the 
same reasons set forth above with respect to the rejection of claims 7 and 9. 

As to claim 1 1 : Claim 11 depends from claims 7 and 9. As such, Applicants respectfully 
submit that claim 1 1 is patentable over Kedem in view of Han and further in view of Bugnion for the 
same reasons set forth above with respect to the rejection of claims 7 and 9. 

As to claim 14 : Claim 14 depends from claim 7. As such, Applicants respectfully submit 
that claim 14 is patentable over Kedem in view of Han and further in view of Bugnion for the same 
reasons set forth above with respect to the rejection of claim 7. In addition, a person of ordinary skill 
in the art would not be motivated to have a destination image as a virtual disk file for the reasons set 
forth above in response to the rejection of claim 9. 

As such, Applicants respectfully submit that claim 14 is patentable over Kedem in view of 
Han and further in view of Bugnion. 

As to claim 24 : Claim 24 depends from claim 21 . As such, Applicants respectfully submit 
that claim 24 is patentable over Kedem in view of Han and further in view of Bugnion for the same 
reasons set forth above with respect to the rejection of claim 21. In addition, a person of ordinary 
skill in the art would not be motivated to have a destination image as a virtual disk file for the 
reasons set forth above in response to the rejection of claim 9. 

As such, Applicants respectfully submit that claim 24 is patentable over Kedem in view of 
Han and further in view of Bugnion. 
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As to claim 25 : Claim 25 depends from claims 21 and 24. As such, Applicants respectfully 
submit that claim 25 is patentable over Kedem in view of Han and further in view of Bugnion for the 
same reasons set forth above with respect to the rejection of claims 21 and 24. 

In light of the above, Applicants respectfully request that the Examiner withdraw this 
rejection. 

Accordingly, Applicants submit that the present Application is in condition for allowance. 
Applicants therefore request reconsideration of the outstanding rejections and issue a Notice of 
Allowance. The Examiner is invited to contact the undersigned at 650-427-1052 to discuss any 
additional changes the Examiner may feel is necessary in light of this Amendment. 

Date: March 31, 2009 Respectfully submitted, 



/Michael B. Einschlag/ 



3401 Hillview Avenue 
Palo Alto, California 94304 
Phone: (650) 427-1052 



Michael B. Einschlag 
Reg. No. 29,301 
Attorney for the Applicant 
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